1. Technical Field
The present disclosure relates to software and, more specifically, to a method and system for software installation.
2. Description of the Related Art
Operating system software, such as Windows Installer, provides computer users with a vehicle to efficiently install and configure products and applications by providing a standard format for component management. Specifically, this system service is responsible for managing the installation, modification, repair and/or removal of applications. To utilize the service, application programs are described in a standard format such as, for example, “Windows Installer Format.” An application program may often include an “installation package”, which may include a self contained data file that contains the requirements and instructions that are followed when applications are installed. During installation, Windows Installer opens up the installation package for the application, and uses the information located therein to determine all of the installation operations that have to be performed for that specific application.
In general, Windows Installer installs and removes an application or product in parts that are referred to as “components”, such as groups of files, registry data, shortcuts, etc. Quite often, multiple applications or products require the use of the same component. When such a situation arises, the method that is recommended by Microsoft for installing a multi-component product is to create a set of “merge modules” for each component and combine them together into a single Windows installation package for each application.
FIG. 1 is a block diagram illustrating the operation of merge modules for Windows Installer. A merge module 16 is created for each shared file (component) 11 that is utilized by multiple applications (A, B, C) 12, 13, 14. When each of the applications 12, 13, 14 installs the shared file, a copy 11 of that file is provided and is used by each application 12, 13, 14. A system history 15 is maintained that keeps track of which applications 12, 13, 14 utilize the shared file 11.
However, as the number of combinations of products and shared components increases, this method poses a problem for several reasons. First, merge modules may present difficulties in testing and installation because they do not support data encapsulation. In other words, they do not hide the implementation details for their data, making it difficult to understand and further develop the merge modules. Second, not only do these “super-installs” become difficult to test and install, but they may also cause the synchronization of releases to increase in complexity, and support/upgrades to become unmanageable. For example, if five different merge modules “A”, “B”, “C”, “D”, and “E” are generated and released at separate times with separate updates, the number of testing and compatibility scenarios significantly increases, resulting in many different possible combinations to be considered. Thus, a need exists for a system and method that overcomes the disadvantages of present-day merge modules and conventional software installation techniques.
Installation methods such as Microsoft's merge module method, for example, allow shared components to be utilized by different applications. However, these methods often may result in the shared components existing multiple times on the same computer.
Accordingly it would be beneficial to provide a method and system for software installation whereby a common component is stored only once on a system with multiple reference counts for each caller that utilizes that common component.